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Abstract: The safety of modern avionics 
relies on high integrity software that can be 
verified to meet hard real-time requirements. The 
limits of verification technology therefore 
determine acceptable engineering practice. To 
simplify verification problems, safety-critical 
systems are commonly implemented under the 
severe constraints of a cyclic executive, which 
make design an expensive trial-and-error process 
highly intolerant of change. Important advances 
in analysis techniques, such as rate monotonic 
analysis (RMA), have provided a theoretical and 
practical basis for easing these onerous 
restrictions. But RMA and its kindred have two 
limitations: they apply only to verifying the 
requirement of schedulability (that tasks meet 
their deadlines) and they cannot be applied to 
many common programming paradigms. 

We address both these limitations by 
applying model checking, a technique with 
successful industrial applications in hardware 
design. Model checking algorithms analyze finite 
state machines, either by explicit state 
enumeration or by symbolic manipulation. Since 
quantitative timing properties involve a 
potentially unbounded state variable (a clock), 
our first problem is to construct a finite 
approximation that is conservative for the 
properties being analyzed — if the approximation 
satisfies the properties of interest, so does the 
infinite model. To reduce the potential for state 
space explosion we must further optimize this 
finite model. Experiments with some simple 
optimizations have yielded a hundred-fold 
efficiency improvement over published 
techniques. 

1 The safety of hard real-time 
software 

Modern avionics relies fundamentally on 


high integrity software that meets hard real-time 
requirements such as schedulability — the 

guaranty that all tasks meet their deadlines. It is 
common to implement a high integrity real-time 
system by means of a cyclic executive, in which 
programmers explicitly allocate the execution of 
processes or process fragments to portions of a 
master control loop. This technique has the 
strengths of requiring essentially no runtime 
support and of making schedulability analysis 
ttivial. But the design of a cyclic executive is 
expensive and time-consuming, relies heavily on 
nial-and-error rather than systematic design 
principles, and is highly intolerant of change. 
Small modifications to individual processes may 
require complete redesign of the master control 
loop, hi addition, this narrowing of the design 
space potentially constrains the introduction of 
automation technologies that could improve both 
safety and performance. 

The alternative to a cyclic executive is some 
form of preemptive scheduling hi which 
processes are scheduled dynamically. Preemptive 
scheduling immediately presents two problems: 
First, static analysis of program behavior 
becomes much more difficult. Second, the 
runtime support required to cany out dynamic 
scheduling must be efficient and must admit an 
implementation simple enough to satisfy the 
certification requirements for high integrity 
systems. Raven [32] is an example of such a 
runtime. 

The best-known analysis technique for 
preemptive scheduling is Rate Monotonic 
Analysis (RMA) [19], which applies to a 
restricted but useful class of systems and reduces 
schedulability analysis to checking a set of 
simple algebraic inequalities. However, RMA 
does not provide information about properties 
other than schedulability and is not applicable to 
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many common programming paradigms: Figure 
1 provides an example of such a program. Nor 
does RMA cover properties other than 
schedulability. 

This paper describes art ongoing investigation 
of model checking as a supplement to RMA. 
Model checking comprises automated techniques 
that apply, in principle, to arty system 
representable as a finite state machine. These 
techniques are of two general lands: explicit 
search (clever strategies for visiting all possible 
states) and symbolic model checking (combining 
symbolic execution and automated reasoning). 
Both styles can be used to analyze properties 
other than schedulability and systems that do trot 
meet the design restrictions imposed by RMA. 
Our work shows that model checking can be 
applied to some systems beyond the reach of 
current analytical techniques. The technical 
barrier to making these applications practical and 
routine is die possibility of state space explosion. 
We are investigating optimization techniques 
tiiat generate efficient representations of the 
system to be analyzed. 

1. 1 Ravenscar and Raven 

Tire general principles we employ ar e not tied 
to any particular implementation, though the 
details will necessarily depend on the 
programming language and runtime system 
being modeled. Tire Ravenscar Profile [8] 
defines a set of Ada tasking features rich enough 
to support (among other things) rate monotonic 
scheduling, but requiring a minimal runtime. 
Ravenscar is supported by the Raven runtime, 
developed at Aonix to meet the highest FAA 
certification standards for safety critical systems. 
The tasking subset we consider can be regarded 
as a generalization of Ravenscar, together with a 
technical requirement, which we call frame 
synchronization, that reduces nondeterminism by 
eliminating arbitrary task phasings. Thus, the 
analysis we propose can be directly applied to 
real systems. 

1 . The mam features of the Ravenscar 
subset are as follows: 

2. The number of tasks, and the base 
priority of each, is fixed and statically 
determined. 

3. Scheduling is preemptive, using the 
priority ceiling protocol. 

4. Tasks interact only through protected 
objects. No more than one task may ever 


be queued on the entry of any protected 
call. (This limit on the size of the entry 
queues is a dynamic requirement that 
cannot in general be enforced by 
syntactic restrictions.) 

5. Task behavior is deterministic. 

Figure 1, based on an example from [16], 
illustrates a simple Ravenscar program to which 
RMA does not apply. Three sensors periodically 
sample flight data and send it via a bounded 
buffer to an analyzer that periodically reads die 
data from die buffer. The buffer is implemented 
as a protected object containing a protected entry 
for writing data and a protected procedure for 
reading it. A read from an empty buffer returns 
some conventional value. The buffer’s write 
entry blocks the sensors from writing when die 
buffer is full. The protected read procedure 
blocks the analyzer from reading while die buffer 
is being written to. (We make die read operation 
a procedure radier dian an entry because 
Ravenscar forbids protected objects with more 
dian one entry. That is why read does not block 
on any empty buffer, but reads some 
conventional value.) RMA does not apply 
because each of die periodic sensor tasks 
contains a protected entry call, at which it can be 
blocked. 

1.2 Model-checking real-time 
properties 

Many existing models for real-time systems 
are based on tuned automata [2] or, more 
generally, hybrid automata [1]. These models 
contain state variables that represent the values 
of real-tune clocks. Notice diat a direct model of 
time, by means of a variable containing die 
current value of the clock, leads to an infinite 
state space, since die clock may increase widiout 
bound. Some form of temporal abstraction is 
required. The abstraction used to analyze hybrid 
automata is to represent regions — sets of 
states — symbolically, via logical formulas. 
Symbolic manipulation of such formulas [20] is 
the heart of model checking tools such as [4]. 

hi [10], Corbett presents a two-stage 
construction that models real-time Ada tasking 
programs (together with the supporting runtime) 
as hybrid automata. The first stage translates a 
program to a transition system representing the 
possible interleavings of the tasks’ execution. 
The second stage captures die timing constraints 
of the program by transforming the transition 




Figure 1: A Ravenscar example to which RMA does not apply 


system into a hybrid automaton. This hybrid 
automaton is then analyzed by the HyTech 
verifier [11], which can be regarded as symbolic 
model checker. 

hi [16], we developed a method for 
constructing models of real-time tasking 
programs in Promela [12], a language for 
specifying communicating sequential processes. 
The program’s tasks and the runtime system are 
represented as Promela processes. The frame 
synchronization requirement mentioned above 
allows us to eliminate the real-time clocks from 
die system’s model altogether and thereby to 
represent the system as a simple transition 
system rather than a hybrid automaton. We 
introduce state variables to keep track of upper 
and lower bounds on the completion time of each 
process, and perform a “dynamic abstraction” of 
these time-related state variables to make the 
state space finite, hi essence, the pah of 
completion times for each process defines the 
region of states in which the process is running. 
This representation is much simpler than 
representation by a logical formula. We then 
analyzed the Promela program with the Spin 
verifier [12], 

Many other formal models have been 
proposed for concurrent real-time systems [3]. 
These include Petri nets [14], tuned automata 
[2], tuned process algebras [17], and real-tune 
logics [13], For the most part, these models are 
intended to represent specification, not 
implementation, hi [5], general tuned automata 
are extended to represent such implementation 
details as the assignment of tasks to processors, 
priorities, worst-case execution times of 
operations, and scheduling policies. Our model 
compares to [5] much as it does to [10], 


2 A simple illustration 

This section uses a trivial example to show 
how the “dynamic time abstraction” of [16] can 
be combined with reduction techniques from 
[10] and illustrate its effectiveness. Although 
there are enough differences that a quantitative 
comparison is not strictly scientific, we obtain a 
hundred-fold advantage over [10] in both speed 
and memory usage and a ten-fold advantage over 
[16]. 

2.1 A schedulability problem 

Consider two periodic, non-interacting tasks, 
A and B, run on a single processor under 
preemptive scheduling. Task A has higher 
priority than B. Although this trivial tasking 
pattern can be analyzed by RMA. it allows us to 
illustrate essential features of our proposed 
strategy and to perform a simple comparison 
with Corbett’s analysis via a hybrid automaton 
model. 

A code skeleton is given in Figure 2. We 
assume that the variable StartTime records the 
value of the system clock at some moment after 
the tasks have been initialized but before they 
start running, hi effect, this implements the 
frame synchronization assumption. StartTime 
can be initialized to satisfy the assumption by 
using a simple Ada coding idiom given in [16], 
The code fragments <statementsl> and 
<statements2> implement periodic activities 
whose functionality is irrelevant to the tasks’ 
timing. Let estimA and estimB be upper bounds 
on the amount of CPLT time necessary to execute 
the bodies of the loops in task A and task B 
respectively. We assume that CPLT time is the 
tasks’ only shared resource. The parameters 








task A is 

task B is 

pragma Priority (20); 

pragma Priority (10); 

end A; 

end B; 

task body A is 

task body B is 

nextA: Time = StartTime; 

nextB: Time = StartTime; 

begin 

begin 

loop 

loop 

<statements1> 

<statements2> 

nextA := nextA + periodA, 

nextB := nextB + periodB', 

delay until nextA; 

delay until nextB; 

end loop; 

end loop; 

end A; 

end B; 


Figure 2 : A two-task problem 


and periodA and periodB define the periods of 
task A and task B. Execution of “delay until t” 
blocks a task until the system clock has value t. 
If task A reaches its “delay until next A” 
statement when the clock time is greater than 
nextA, then task A has missed a deadline. We can 
characterize a missed deadline for task B 
similarly. 

With this definition of deadline, we analyze 
the schedulability of tasks A and B in terms of 
the task periods periodA and periodB, and tire 
CPU time estimates e stint A and estimB. As 
noted, RMA handles the problem easily, but the 
point of the example is to exhibit simple 
optimization strategies that can dramatically 
improve the efficiency of analysis by model 
checking. 

2.2 A discrete model 

hi the program of Figure 2, the only variables 
affecting the timing behavior of the program are 
nextA and nextB. They are the only data variables 
represented in our model. 

To model the program’s control state, we 
completely abstract from the code fragments 
within the task loops. We represent the 
fragments as abstract actions whose executions 
take time, and whose executions can be 
preempted by higher priority actions. We model 
execution of tasks A and B as periodic 
invocations of these abstract actions. 

hi [16] we represented the runtime and each 
task as a separate process. As observed in [10], 
this simple-minded representation introduces 
unnecessary states because the actions of the 


runtime are so tightly coupled to the actions of 
die tasks. That is, we know a strong invariant 
tiiat permits a more efficient abstraction of die 
state space. Because task A has higher priority 
dian task B, we can partition die system states as 
follows: task A can be eidier running or blocked 
by its “delay until” statement; task B can be 
running, or blocked by its “delay until” 
statement, or preempted by task A; and the 
system as a whole enters an error state if either 
task misses a deadline. Thus, we represent die 
status of the program by introducing a variable 
runtime status that can have the following 
symbolic values: runningA preempted!!, 

blockedA runningB, blockedA blockedB, 

runningA blockedB , and missed deadline. 

We also introduce several valuables to model 
timing information: 

1. The integer variables lb and ub specify 
lower and upper bounds for die clock 
time at which the currently executing 
abstract action will (if not preempted) 
complete. The values of these time 
bounds vary dynamically, according to 
the program’s control flow. 

2. The integer variable delta contains an 
upper bound for the CPU time needed to 
complete the currently executing abstract 
action. When a preempted action 
resumes its execution the value of delta 
will typically be revised to reflect die 
progress made before preemption. 

3. The integer variable preernptB, called the 
preemption bound, stores the value of 
delta when task B is preempted by A. 

We specify the schedulability requirement by 




asserting that the runtime status missed deadline 
never occurs: 

Invariant "hard deadline" 

! runtime_status = missed_deadline 

The states and transitions of our model are 
shown graphically in Figure 3. We define die 
effect of each transition using die notation of die 
Murphi model-checker [33], The meaning of 

guard = = > Begin <statements> End 

is diat die transition may take place when die 
boolean guard is true; and, if it does take place, 
die effect on die state variables is defined by die 
Pascal-like code in statements. If several 
transitions may take place, then die choice of 
which transition to fire is non-deterministic. 
(Even if die Ada code is deterministic our model 
may be a conservative, non-deterministic, 
approximation.) The simple model shown here 
does not represent die overhead atdibutable to 
runtime actions such as preempting a task or 
restoring die state of a preempted task. Those 
costs are accounted for explicitly in [16]. 

Figure 4 provides definitions for duee 
representative transitions: 1, 2, and 4. Transition 
rules 1 and 2 describe the program’s behavior 
when A is running and B is preempted. Rule 4 
describes one of the possible behaviors of die 
system when task A is blocked and task B is 
running — namely, the possibility that task A may 
preempt task B. 

Rule 1: If the upper estimate of the clock 
time for completing task A is greater than or 
equal to the next deadline — that is, ub > 
nextA+periodA — then it is possible that A may 
miss its deadline; and therefore a deadline 
violation will be reported. Our model is a 
conservative approximation of the program. The 
program will satisfy any invariant satisfied by 
the model, but the converse need not be true. 

Rule 2: If ub < nextA+periodA, this iteration 
of task A will meet its deadline. Transition 2 
represents the successful completion of A, after 
which A becomes blocked until the beginning of 
its next period, and hands off to task B (as 
reflected by changing the value of 
runtime status to blockedA runningB). To do 
the necessary bookkeeping, the other state 
variables are modified as follows: 


• nextA, die next clock tune at which task 
A becomes ready to run, is incremented 
by the value of its period, 

• delta, die estimate of die remaining CPU 
time to complete task B, is restored to 
die preemption bound of B, 

• ub, which now represents an upper 
estimate of the clock time at which task 
B will complete, is increased by delta, 

• since die preemption of B has now been 
accounted for, we reset preemptB to 
zero. 

Rule 4: The guard for transition 4 represents 
die following possibility: task B will, if not 
preempted, meet its deadline; but task A becomes 
ready before die action of task B completes and 
dierefore preempts B. Among die actions of rule 
4, die interesting new feature is a call to 
procedure time wrap, which is essential for 
making our model finite. 

The state variables nextA, nextB, lb, and ub 
are regularly incremented. If we allowed them to 
increase witiiout bound our model's state space 
would be infinite. However, die presence or 
absence of a deadline violation depends only on 
die relative values of tiiese variables, not on their 
absolute values. Therefore, die relevant timing 
behavior of our model does not change if we 
recalibrate by simultaneously decreasing nextA, 
nextB, lb, and ub by the same amount. Procedure 
time wrap does the recalibration, decrementing 
all these variables by the current value of lb. Our 
transition rules will invoke timewrap 
immediately after any increment to lb. This is a 
form of rolling, dynamic time abstraction. 

This recalibration strategy will succeed in 
bounding the values of these variables if die 
differences between the values of nextA, nextB, 
lb, and ub are bounded. It is shown in [16] diat, 
for all the executions of the model in which no 
deadline is missed, the absolute values 
\nextA—lb\,\nextB -!b\, and I ub-lb\ will all be less 
than 2*max(periodA, periodB). Therefore we can 
statically restrict the range of the tune variables 
to -MAX .. MAX, where MAX=2*max(periodA, 
periodB). To be more precise, if there is a 
deadline violation in the infinite model (from 
which all occurrences of time wrap have been 
deleted), then there is a deadline violation in the 
recalibrated model, and it will be detected before 




Rule "1" 

Rule "2" 

Rule "4" 

runtime_status= 

runtime_status 

runtime status = blockedAjunningB 

runningA preemptedB 

runningA_preemptedB 

& ub < nextB + periodB 

& ub >= nextA + periodA 

& ub < nextA + periodA 

& nextA < ub 

==> 

==> 

==> 

Begin 

Begin 

nextA := nextA + periodA; 

Begin 

runtime_status := 

runtime_status := 

runtime status:=runningA_preempte 

missed deadline; 

blockedArunningB; 

dB; 

End; 

delta := preemptB; 
ub := ub + preemptB; 
preemptB := 0; 

End; 

preemptB := (ub - nextA < delta) ? 

(ub - nextA) : 

delta; 

delta := estimA; 
lb := nextA; 
ub := nextA + estimA; 
time wrap(); 

End; 


Figure 4: Representative transition rules 


execution of the model attempts an update that 
puts these variables out of range. 

2.3 A comparison 

Our experiment analyzed the example of 
section 2.1 in three ways: We applied Murphi to 
the transition system defined in section 2.2; we 


applied HyTech to the hybrid automaton 
constructed by the methods of [10] alone; we 
applied SPIN to the model constructed by the 
methods of [16] alone. The comparison with 
[10], for various values of the parameters, is 
shown in the charts below. 

We suspect that that the advantage of these 





















estimA=5, period A = 10, 

estimB = 10, periodB = 30 

Transition system 

Hybrid automaton 

Number of states! regions 

11 

8 

CPU time (sec) 

0.10 

0.24 

Memory used 

IK 

0.82M 


estimA = 29, periodA = 59, 
estimB = 61, periodB = 181 

Transition system 

Hybrid automaton 

Number of states! regions 

1002 

480 

CPU time (sec) 

0.10 

13.73 

Memoiy used 

25 K 

4.53M 


estimA = 167, periodA = 353, 
estimB = 313, periodB = 997 

Transition system 

Hybrid automaton 

Number of states! regions 

5013 

2700 

CPU time (sec) 

0.40 

106.95 

Memory used 

163K 

20.13M 


Figure 5 : A comparison 


optimizations will increase as the timing 
constraints become more complex, because 
manipulating integers is more efficient than 
manipulating linear formulas with integer 
coefficients. We cannot quantify how much of 
the difference might be attributable to the fact 
that Murphi is a more mature tool than HyTech. 

The advantage over [16] is not quite so 
dramatic — the improvement is one order of 
magnitude, not two. 

2.4 Other properties 

This section briefly considers problems other 
than schedulability. The model and the size of 
the state space depend on the property analyzed. 
For example, hi the terminology of Figure 2, it is 
easier to analyze the assertion that “Both tasks 
always meet then deadlines” than to analyze the 
assertion “Task B always meets its deadlines,” 
because uncertainty about the behavior of A 
would add nondeterminism to the model. Since 
the tasks of Figure 2 do not interact (except 


implicitly, via preemption) there is not much to 
ask about this example aside from its 
schedulability. 

When tasks do interact, things become more 
interesting. The Ravenscar rules require that no 
more than one task be waiting on the entry of 
any protected call. The main purpose of this 
requirement is to avoid the overhead of 

maintaining queues, hi general, it is undecidable 
whether a program meets the requirement, 
though compliance could be guaranteed by 
making severe static semantic restrictions on the 
code. The Raven runtime raises an error 
dynamically if execution ever violates the 

requirement. Thus, it is important to be able to 

check this rule by static analysis. A 

schedulability model of the kind suggested in 
this section already encodes enough information 
in its state to answer this question. Analysis of 
the length of entry queues is insensitive to die 
recalibration trick. 

Deadlock freedom is another interesting 









question that should be amenable to our 
techniques. The priority ceiling protocol itself 
suffices to guarantee that a certain class of 
tasking programs cannot deadlock, but the 
general question is undecidable. (This problem 
is also insensitive to recalibration.) 

2.5 Limitations 

We might hope for a divide-and-conquer 
approach whereby knowing that die system is 
schedulable — for example, in cases where RMA 
is applicable — might permit us to produce a 
simpler model widi which we might verify other 
properties. However, if die precise timing 
behavior of the program is necessary to 
guarantee diose properties, we must represent 
diat behavior in our model and dierefore encode 
die schedulability problem within it. hi effect, 
verifying schedulability is automatically part of 
verifying any property at all. Unfortunately, die 
intricacies and timing of task interleavings are 
die principal source of state space explosion. 

Our experience dius far suggests diat die 
effectiveness of our mediods will depend more 
on die underlying set of tasking primitives than 
on a discipline restricting die patterns hi which 
diey are used. Interrupts are especially 
interesting, and present special problems. In die 
model of [16] we found that code with interrupts 
typically resulted hi a state space explosion. 
Symbolic model checking may be applicable to 
this case. On the other hand, several taskhig 
constructs omitted by the Ravenscar Profile seem 
amenable to model checking analysis: absolute 
delay statement; rendezvous; select statements. 

3 More realistic examples 

This section briefly describes the application 
of our model-checking techniques to more 
realistic examples. We summarize experiments 
ushig the methods of [16] on a modest work 
station, which we have not had the opportunity 
to repeat with the optimizations proposed above. 
These examples employ the mam Ravenscar 
taskhig constructs such as “delay until” 
statements, protected procedures and entries, 
interrupts, and sporadic tasks triggered by 
interrupts. 

The modeling of interrupts and sporadic tasks 
is the most complicated part of the model of 
[16], Conceptually, a sporadic task is triggered 
by an interrupt and must complete its response 
interrupt within a specified response time. Each 


interrupt is characterized by its minimum 
interarrival time — the minimum time between 
two consecutive occurrences of the interrupt. 
The minimum interarrival time and the response 
time for each interrupt are parameters of the 
model. 

To implement sporadic tasks we use an Ada 
idiom required by the Ravenscar programming 
discipline: The response to an interrupt I is 
performed by a sporadic task T whose body is a 
loop. The head of that loop is a call on a 
protected entry E, so that task T is blocked at the 
head of the loop so long as entry barrier of E is 
false; and the last act of the loop is to reset the 
entry barrier of E to true. The text of an Ada 
program binds interrupt / to a protected 
procedure P, which will be executed by the 
runtime whenever 7 occurs; and, in this 
programming idiom, P must be implemented so 
that its only effect is to change the entry barrier 
of E from false to true. Thus, when interrupt 7 
occurs, the runtime executes P, which sets the 
barrier of E to true; that unblocks task T, which 
performs the response to the interrupt, resets the 
barrier of E to false, and becomes suspended. 

We permit tasks to contain both “delay 
until” statements and entry calls. For our 
purposes, a task containing a “delay until” 
statement is periodic. A sporadic task contains a 
call on a protected entry whose barrier is set by 
an interrupt handler. Since we impose no upper 
limit on the interrupt hiteran ival tune, a sporadic 
task cannot be guaranteed to satisfy any periodic 
deadline. For this reason, sporadic tasks may not 
contain ‘delay until' statements. The Promela 
code checks that all periodic tasks meet their 
deadlines and that the response to every interrupt 
completes within the response tune. 

We have analyzed several systems containing 
both periodic and sporadic tasks, all on a 
SparcServer20 with 64 megabytes of memory. 

One is a toy pump control system [29] often 
used as a benchmark example, which our 
techniques handled in seconds. With some more 
complicated systems, however, the model of [16] 
encountered a state space explosion. We describe 
two such examples: 

1 . the Olympus attitude and orbital control 
system (AOCS) [30], 

2. a brewery control program [31]. 

A pump controller 

The pump control system has the following 
components: 



1 . four periodic tasks getting data from die four 
sensors and controlling die pump, 

2. a sporadic task, triggered by the interrupt 
from a high/low water level detector, diat 
controls die pump, and 

3. two protected objects for die pump and die 
interrupt interface. 

Verification of diis program took 20 seconds. 
The AOCS 

The AOCS design contains 17 protected 
objects, 4 sporadic tasks driven by interrupts 
(with short interarrival tunes), and 10 periodic 
tasks (widi relatively long periods). We were 
able to verify a reduced version widi all 10 
periodic tasks and only one sporadic task 
(roughly 1.5 hours of computation). Adding a 
second sporadic task resulted hi a state space 
explosion diat SPIN could not handle. 

A Brewery controller 

Our techniques successfully identified a 
timing error hi the brewery control program, but 
the analysis required some abstractions 
performed by hand, not merely the “standard” 
abstractions used to represent die pump 
controller. 

The brewery control program contains no 
interrupts. It consists of an alarm task suspended 
on a protected entry, several short-period tasks, 
and one long-period task that calculates a 
“pattern temperature.” One of the short-period 
tasks compares the actual temperature to the 
pattern and, if the difference between the 
temperatures is too great, opens the entry barrier 
to trigger the alarm. We model the decision 
about whether to trigger the alarm as a 
completely nondeterministic event (a 
conservative approximation). 

We may eliminate the long-period task 
altogether if we assume that the pattern 
temperature is constant. Under that assumption 
(also conservative) our methods took 6 minutes 
of computation to find a timing violation. 

If we do not assume that the pattern 
temperature is constant, the combination of a 
long-period task widi a short-period task 
nondeterministically triggering another task 
results in a state space explosion (as explained 
below). 

The size of our model’s state space is 
proportional to S p , where: 

1. P is the number of possible patterns of the 
periodic tasks’ arrival times. (A task arrives 


whenever it begins a new period.). P is 
roughly proportional to (MID), where M is 
die least common multiple of die task 
periods and interrupt interarrival times, and 
D is dieir greatest common divisor. 

2. S is die average number of non-deterministic 
choices exercised by the model during die 
execution of any one pattern of arrival times. 
A common source of non-determinism is die 
runtime process controlling task preemption. 
However, diis nondeterminism is usually 
restricted, since die control-delegating 
conditions in die runtime process are often 
mutually exclusive. Thus, die runtime 
process does not contribute much to die size 
of S. On die odier hand, nondeterministic 
behavior in a short-period task will increase 
S, since diis behavior is exercised in die 
many patterns where die task is running. 

Our problem with die brewery control 
program is diat die short-period task 
nondeterministically triggers the alarm, which 
increases S. We can still analyze the program if 
P is low, but including die long-period task 
increases P. This combination increases S p 
sufficiently to cause a state explosion. 

As for the interrupts, in [16] we model each 
interrupt by a Promela process representing a 
“quasi-task” that makes calls on die protected 
procedure that is its handler. The behavior of 
such a task is in many respects similar to die 
behavior of a periodic task that non- 
deterministically executes the interrupt handler 
and has a period equal to the interrupt’s 
minimum interarrival tune. 

4 Future research 

Our primary technical problem is how to 
optimize the model for efficient model-checking. 
The optimizations described in section 2 — the 
runtime status abstractions, the encoding of 
regions as pah s of integers — are specific to our 
problem domain and to the kinds of properties 
being analyzed. There is an extensive literature 
on general-purpose algorithms for abstractions 
and optimizations of untuned transition systems, 
and on the automated discovery of invariants. 
(See, for example, [21-24]). Future research will 
consider the applicability of that literature to our 
problem. 

Symbolic model checking is another 
possibility for dealing with state space explosion. 
Problems that do not yield to explicit search 



techniques can sometimes be solved by symbolic 
model checking (and vice versa). The state- 
machine model accepted by a symbolic model 
checker is typically quite low-level and 
constrained. Not all symbolic model checkers 
permit variables of integer type. But some, such 
as WSMV [9], are able to treat integers and 
certain integer operations symbolically by using 
special encoding techniques that permit efficient 
representation of addition and integer 
comparisons, and those are precisely the 
arithmetical operations our methods require. 
Tlius, WSMV is a promising engine for 
extending our results with symbolic model 
checking. 
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